Re: /etc/utmp
Pat Myrto (ole!rwing!pat@nwnexus.wa.com)
Mon, 28 Mar 94 12:59:26 PST
"In the previous message, Marc W. Mengel said..."
>
>
> In <9403252218.AA14294@rwing.UUCP> you write:
> I don't know of a specific patch, for this. But the only REAL fix is
> to make the /etc/utmp file so it is not world-writeable. That means,
> of course, fixing anything that must update it, other than login or init
> to run SUID root without creating a worse hole.
>
> To quote our President: "NO NO NO NO NO NO NO ..." :-)
>
> Making things setuid root is almost always wrong. Make a new group,
I guess I didn't make myself totally clear. I said the fix was to make
utmp not world writtable (and I believe I mentioned a workaround using
a group (the tty group temporarily, since only staff types would be using
xterms on the given system). But the fact remains Xterm really needs to be
SUID root so it can change perms and OWNERSHIP on its pty to the user.
As for just locking down utmp, as you say, an empty group, such as utmp
would be a great idea. Except for one minor problem: See, MOST things
that need to write to utmp also have to open a port or pty, and the
ownership of that assigned port or pty is undefined - it could be root,
or some other user. It either has to be world writeable AND readable,
or chowned to the ID of the current user so that user can use more sane
permissions to function. I'm not sure I would really want to be forced
to have world-read/write access perms on a port cuz I cannot set it to
mode 600 or 660 because I am not the OWNER of that port.
But since xterm was SUID root to accomplish this, and a bug in XTERM
made it possible to alter system files, Sun's apparant fix was to
make utmp world-writeable, all the pty's world-writeable, and remove
the SUID bit from Xterm. Only folks logging at the CONSOLE (not an
xterm) had an alternative on port permissions via the /etc/fbtab, but
this still doesn't address ptys, since one cannot know beforehand what
pty one is going to get, and its kinda rude to put them ALL in fbtab.
And not being able to write to utmp somehow results in other apps
blowing up because they think the user isn't logged in (w, or who
doesn't list the user because the user isn't entered in utmp unless
that user came in via login ON THAT PORT, which updates utmp and
chowns the port before it gives up its root privs.
> say group "utmp", and make anything that needs to deal with utmp
> setgid utmp; similarly for mail, etc. That way if you have something
> that needs to do mail and utmp, you can just put it in multiple groups.
> Similarly ps and friends should be setgid "kmem", and kmem should be
> readable by group "kmem". It's just the principle of least priveledge
> applied to good old fashioned UNIX.
That's great on SysV, where a user can change ownership, but not on BSD
derived systems where one cannot, not even to 'give a file away'. And
it still doesn't solve the problem where the unused pty one gets assigned
is owned by root or foo, and it needs to be owned by you (assuming you
aren't root or foo), or force you to live with world-write perms. Setting
it to exclusive open has other problems (like /dev/tty doesn't work).
> If our vendors did things this way out of the box, there would be far fewer
> things running as root on our systems, and far fewer security problems to
> begin with. [There are even schemes to make things like cron and at not
> have to be root (The user creates an executable setuid to them that cron
> will run.)]
Granted. Please enlignten me as to how a user can ensure that they own
the given pty they get from the system for windows opened on an xterminal,
without having it world read/writeable so the user can even acceess it (and
so everyone ELSE can access it, too).
> Okay, I'll get down off my soapbox now... But remember, next time you hear
> someone suggets making something setuid root, see if you can deal with the
> problem with a nice, separate group id, and setgid instead.
No argument here. I just cannot see how one can deal with the problem
without either having to live with not having full control of ones own
tty port or have SOME root process to chown it and also update utmp
while it is at it, before it gives up root privs. A SGID utmp program
cannot chown the given pty or tty to the user...
One could use a variation on that pty command available off the net,
it works fine, but, alas, *IT* has to run SUID root, too in order
to be able to chown the pty to the user...
--
pat@rwing [If all fails, try: rwing!pat@ole.cdac.com] Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence." -- Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.